-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add no_std support #294
base: master
Are you sure you want to change the base?
Add no_std support #294
Conversation
Rather than adding the It's unfortunate that the |
@kevinmehall for hashbrown how should we expose the type for user input as a macro in the grammar? It should be allowed in Rust right?
but wouldn't that attach cache_map_type attribute to Since both HashMap and BTreeMap does not have a common set of trait, maybe we should make a specialization for the cache as a minimal set of functions required so user can supply a custom cache implementation without having to worry about the type recursion problem as well. |
Hmm, we could make use of |
A proc macro gets everything inside of the Yes, we'd want to document what methods the map type must have. It already injects |
Agreed, so should we further attach the cache type information to I've also starting to think about repeated tokens, as the use of Vec type (either std::vec::Vec or alloc::vec::Vec) means it is not allocator-free. can also be treated the same way to have a fixed set before overflowing to make it very suitable for parsing data with formal structure in kernel. It also helps for people who use immutable data structure in compiler, but the way it works is not the same (rather than directly pushing into the vector |
I think we should make the cache type a facade trait that can be defined by the user externally rather than applying it in macro time. This way we can have better flexibility because we can even use it for things like tracing -- capturing the event when a rule is cached and observe what is going on. |
This patch will replace the use of
std
crate to theirno_std
equivalent. One notable change is thatpeg_runtime::error::ExpectedSet
would use BTreeSet instead of HashSet before, as I observed that the expected set order is random during a parser debug.I did not add a HashSet shim for
peg_runtime::error::ExpectedSet
because this technically means the underlying structure can be changed many times over. Although it wouldn't hurt that much since it is not exposed, this could cause confusion on document generation. This does imply that the expected order will be based on lexicographical order and I do think this would make it more stable which is a nice thing.